Seems like you should update

https://github.com/GeorgeTsagk/lightning-terminal/blob/c7dbe80f1b6463bb01fe2f94f72cf52b6b6ab9de/itest/litd_custom_channels_test.go#L2973-L2977

to mention the send test, possibly renaming the function name?

In the following topology

	  /---[sats]--> Erin --[assets]--\
	 /                                \
	/                                  \

 Charlie  -----[sats]-->  Dave  --[assets]---->Fabia

	\                                  /
	 \                                /
	  \---[sats]--> Yara --[assets]--/

Do we see any value in adding tests where Charlie has more or less channels than Fabia? Like this route seems a bit too simple because both sender and receiver kind of need the same sharding.

I'm also wondering if we should test where Charlie-Dave have asset channels and not sats channels.

I don't think this test should be removed, but I think there should be some more complex network that tests more than what this test can do in another function.

Linter / unit tests fail because of this
https://github.com/lightninglabs/lightning-terminal/actions/runs/16022889778/job/45203816341?pr=1097#step:5:317

accounts/sql_migration_test.go:340:19: undefined: sqldb.MigrationTxOptions (typecheck)

which is not related to this PR, the itests should normally run & pass

The last commit adds a new node to the topology, which always rejects quotes, causing a reliable RFQ negotiation failure this way

The tests pass, but they do now expose some potential bug in the RFQ negotiation code where we hang until timeout if the rfq negotiation is not successful.

@ffranr: review reminder
@GeorgeTsagk, remember to re-request review from reviewers when ready

Need to remove the replace in go.mod, and some other outstanding comments, otherwise good to go.

FYI: I made a branch where I rebased and then updated all the packages. Not sure if you want to use it or re-do it another way.

https://github.com/ZZiigguurraatt/taproot-assets/tree/group-key-addr-part-2%2Bmulti-rfq-send

Need to remove the replace in go.mod, and some other outstanding comments, otherwise good to go.

FYI: I made a branch where I rebased and then updated all the packages. Not sure if you want to use it or re-do it another way.

https://github.com/ZZiigguurraatt/taproot-assets/tree/group-key-addr-part-2%2Bmulti-rfq-send

sorry, got this PR mixed up with the other one.

@GeorgeTsagk can you please rebase this to the tapd-main-branch branch? We can't bump tapd on master branch yet, as we're not ready to release what will become tapd v0.7.0 yet (in case we need to do an emergency minor release of litd).

@GeorgeTsagk can you please rebase this to the tapd-main-branch branch? We can't bump tapd on master branch yet, as we're not ready to release what will become tapd v0.7.0 yet (in case we need to do an emergency minor release of litd).

do we want to prio lightninglabs/loop#968 now so that this can be done more cleanly?

Rebased on tapd-main-branch

do we want to prio lightninglabs/loop#968 now so that this can be done more cleanly?

We can't merge the loop PR until the tapd PR gets merged, as we have to provide the final go mod ref

Can you rebase this please so we can merge this to fix the tapd CI?

Can you rebase this please so we can merge this to fix the tapd CI?

Hey

Currently blocked on this lightninglabs/loop#968

Then we can finalize this PR and merge

That loop PR doesn't have to be merged, since we're merging into a temporary side branch here as well (to which the tapd CI currently points).

After addressing some of the latest feedback in the tapd PR I realized that some errors/RPC responses had changed, which required some fixes on this side. It's good now